home *** CD-ROM | disk | FTP | other *** search
/ Hacker's Arsenal - The Cutting Edge of Hacking / Hacker's Arsenal - The Cutting Edge of Hacking.iso / texts / nix / linux_sec.txt < prev    next >
Encoding:
Text File  |  2001-07-11  |  48.4 KB  |  1,122 lines
  1. Another Paper on Linux Security
  2.  
  3. 13 Aug 98
  4. Last Update 07 Sept 98
  5. Version Beta 0.2
  6.  
  7. Bronc Buster
  8. bronc@shocking.com
  9.  
  10. ------------------------------------------------------------------------
  11.  
  12.   Another paper on Linux Security? Why? Well most of the ones I've seen
  13. floating around the net are never complete, only someone's tips or 
  14. tricks on how to secure a part of it, or to tweak some daemon or process 
  15. or a quick fix to a problem. They never cover from step one, though 
  16. going multi-user and going online with users and user processes and all 
  17. that goes along with it. I want to cover that. I know, no matter how 
  18. hard I try, I'll end up missing something, but I'm going to try and 
  19. cover everything I do when I install a system and prepare it for online 
  20. use, plus cover some free tools that I have found to be very effective. 
  21. Now if you are totally clueless and don't have any idea about how to use 
  22. Linux, I'll save you some time and tell you now, just don't go any 
  23. further. To get any use out of this paper, you have to be an 
  24. intermediate user, or a new admin who is familiar with Unix as a whole. 
  25. If you are thinking about going by this list when you are installing 
  26. your system, READ THIS ENTIRE PAPER FIRST, then start over following it, 
  27. otherwise you may miss something you might want when you install or when 
  28. you pick a kernel.
  29.  
  30.   I'll say this now before you start. This paper is ongoing, and a
  31. work in progress. I want to make a comprehensive paper, so I welcome all 
  32. suggestions, tips and advice on how to make this paper a better one.
  33.  
  34. ------------------------------------------------------------------------
  35.    Contents
  36.  
  37. 1. Installation
  38. 2. Boot-Up
  39. 3. SUID files and the File System
  40. 4. Quotas
  41. 5. Logs
  42. 6. Access security (remote and physical)
  43. 7. Misc. Files
  44. 8. Third Party Tools
  45. 9. Conclusions
  46.  
  47.  
  48. ------------------------------------------------------------------------
  49. 1. Installation
  50.  
  51.   This is a step every paper I have seen has over looked. Right from
  52. install you can manage to cut your problems by at least one-third if you
  53. install correctly, installing only what your system needs. Think about 
  54. it. Ask yourself what is this box going to be doing? Is it going to be 
  55. on a LAN as a file server of some sort, or sitting on a direct Internet
  56. Connection as a web server of some sort, or just sitting on your
  57. desk at home running PPP? These are important questions you need to 
  58. answer BEFORE you start your install. 
  59.  
  60.   If this system is going to be sitting on a rack as a web server, why
  61. would you want to install X-Windows, for example. If you're not going to
  62. use it, you'll most likely overlook it in day to day operations, and
  63. that's something a hacker is going to look for. Along with this comes 
  64. SUID programs, programs you might not even know exist, but programs a 
  65. hacker will head for like a shark for blood. On the other hand, if it's 
  66. on a LAN, where you're going to be at the console, and an X-Windows 
  67. server is necessary, look for other components you won't need, like any 
  68. of the PPP or SLIP components.
  69.  
  70. If you're not sure, go out and buy a book, or if you're really poor,
  71. borrow a book. Read up on what each component does and why you need it. 
  72. If worse comes to worse, when you are installing, read each section 
  73. before you just go down the line and check off everything. Read the 
  74. parts which you are unsure of and don't install what you think you don't 
  75. need. Remember that you can always go back later and add things. The 
  76. Unix file system can be very complex and very deep, and hackers depend 
  77. on this when they are hiding programs and backdoors. The better you 
  78. understand what you have put on your system, the better you will know, 
  79. later on, what should be there and what shouldn't. This also helps out 
  80. later on after you have installed, when you are weeding out potential 
  81. security risks. The less unnecessary stuff on yo4ur system, the less you 
  82. have to worry about later on, so take the time now, before an install, 
  83. and go though what you want to install.
  84.  
  85. ------------------------------------------------------------------------
  86. 2. Boot-Up
  87.  
  88.   Ok, so you took a couple hours and got a nice clean install, now 
  89. you're booting up. Hopefully it'll be clean with no errors. If there are 
  90. errors, there are the first problems you want to try and solve. In Linux
  91. (Slackware), there is a directory called '/etc/rc.d' that hold the files
  92. that tells the system what to run at boot. This, as you can imagine, is 
  93. a very important directory, as someone who can write to these files can
  94. install a backdoor, or a process that can be harmful to your system.
  95.  
  96. Back to the errors, and editing each of the files for safety. Most 
  97. people, unless they have experience with Linux, either don't know these 
  98. files exist, don't know what to do with them, or are to scared to touch 
  99. them, thinking back to their uninformed windows95 days, where if you 
  100. touched files that controlled boot-up you might lose everything and have 
  101. to reinstall the operating system. Fear not, this is Linux!
  102.  
  103. showdown:/etc/rc.d# ls -l
  104. total 40
  105. lrwxrwxrwx   1 root     root            4 Jun  5 01:31 rc.0 -> rc.6*
  106. -rwxr-xr-x   1 root     root          396 Oct  2  1995 rc.4*
  107. -rwxr-xr-x   1 root     root         2273 Oct 17  1996 rc.6*
  108. -rwxr-xr-x   1 root     root         1244 May 21  1997 rc.K*
  109. -rwxr-xr-x   1 root     root         3439 Sep 25  1997 rc.M*
  110. -rwxr-xr-x   1 root     root         5054 Jun 16  1997 rc.S*
  111. -rw-r--r--   1 root     root         1336 Jul  9  1997 rc.cdrom
  112. -rwxr-xr-x   1 root     root           52 Jun 12 12:24 rc.httpd*
  113. -rwxr-xr-x   1 root     root         2071 Jul 29 14:19 rc.inet1*
  114. -rwxr-xr-x   1 root     root         2846 Jul  2 20:41 rc.inet2*
  115. -rwxr-xr-x   1 root     root          735 Jun 30 22:10 rc.local*
  116. -rwxr-xr-x   1 root     root         5251 Jun  5 09:23 rc.modules*
  117. -rwxr-xr-x   1 root     root         9059 Aug 23  1997 rc.serial*
  118.  
  119. Now here is a typical '/etc/rc.d/' directory. Each of the 'rc.*' files
  120. does something specific, depending on the status of the system. Some of
  121. them are self-explanatory, like 'rc.httpd', it's simply starts your 
  122. HTTPD web server. The 'rc.cdrom' loads your CD-ROM drive, if you have 
  123. support compiled into your kernel. 'rc.modules' loads modules, if you 
  124. have any (modules are special drivers or programs that are added at 
  125. boot-time to the kernel, and are not compiled into the kernel. Modules 
  126. are uses for older type NICs, sometimes Modems and other old types of 
  127. hardware.) 'rc.serial' is also used for loading serial devices, like 
  128. modems, printer and other stuff. Most of the 'rc.*' files that have 
  129. proper names, like '.cdrom', '.modules', '.serial' and '.httpd' you 
  130. shouldn't have to mess with, as they are set up automatically by the 
  131. choices you make when you install and select a kernel to boot off of. 
  132. Some of the others control the differences between Single Users Mode and 
  133. Multi User Mode, and some of the others control what daemons load up and 
  134. what your operating system can do.
  135.  
  136.   'rc.M' controls the system going to Multi User Mode and loads some of
  137. the other 'rc.*' files if the are supported, like the 'rc.cdrom', etc. 
  138. Go through this file carefully! Anything you know for a fact you don't 
  139. need, EDIT OUT with a '#'. Most likely there won't be too much you have 
  140. to mess with in this file, but you will in the others. Go down the list 
  141. in the 'rc.M' file and look at each of the other 'rc.*' files it runs. 
  142. Then go though each of these files and repeat the process.
  143.   
  144.  For example, say you are going through your 'rc.inet2' file and you 
  145. know you don't need any 'rpc' services and you don't want your 
  146. portmapper to run, so you want to edit this out so it won't start up.
  147.  
  148. #This is how it looks normally. To edit it out, use the '#'
  149.  
  150. -- snip ----
  151. # Start the SUN RPC Portmapper.
  152. if [ -f ${NET}/rpc.portmap ]; then
  153.    echo -n " portmap"
  154.    ${NET}/rpc.portmap
  155. fi
  156. -- snip ----
  157.  
  158. #Here is the correctly edited version
  159.  
  160. -- snip ----
  161. # Start the SUN RPC Portmapper.
  162. #if [ -f ${NET}/rpc.portmap ]; then
  163. #   echo -n " portmap"
  164. #   ${NET}/rpc.portmap
  165. #fi
  166. -- snip ----
  167.  
  168.   It is important to edit it all out, from the starting 'if' all the way
  169. down to the corresponding 'fi' at the end, otherwise you'll end up with
  170. errors. I could go through each of the files and programs started in 
  171. each of the 'rc.*' files, but only you know which ones you are going to 
  172. need, depending on the type of server you are going to run. Just 
  173. remember, you have to assess what you need to get the job done, and then 
  174. remove the rest. If you're not sure what each program does, try doing a 
  175. net search, then reading on what each program does and then assessing if 
  176. you need them or not.
  177.  
  178. The 'rc.local' file is also an important file in the 'rc.d' directory, 
  179. it has any files or program you want to add to be started at boot time. 
  180. You can put any sort of things in here as you will see when I add one a 
  181. bit later.
  182.  
  183.  
  184. ------------------------------------------------------------------------
  185. 3. SUID files and the Filesystem
  186.  
  187.   Before a single user steps fourth into my system, I make sure I find, 
  188. and isolate all, I repeat ALL, SUID files on the entire system. First, 
  189. you need to find all the SUID files. These series of commands will show 
  190. you where they all are:
  191.  
  192. find / -perm 4000 >> suid.txt
  193. find / -perm 4700 >> suid.txt
  194. find / -perm 4777 >> suid.txt
  195. find / -perm 4770 >> suid.txt
  196. find / -perm 4755 >> suid.txt
  197. find / -perm 4750 >> suid.txt
  198. find / -perm 4751 >> suid.txt
  199. find / -perm 4500 >> suid.txt
  200. find / -perm 4555 >> suid.txt
  201. find / -perm 4550 >> suid.txt
  202. find / -perm 4551 >> suid.txt
  203.  
  204.   Now all you have to do is take a quick look into `suid.txt' and you'll 
  205. have the paths to all the SUID files on your system. On some systems, a 
  206. simple `find / -perm 4000 -print >> suid.txt' or 'find / -perm +4000 
  207. -print >> suid.txt' command will do the same thing as all the commands
  208. above, but then again I've had a system in  which it didn't show all the
  209. SUID files for some reason. So to be safe I use a simple script in which
  210. it just runs all these commands at once so I don't have to sit around
  211. typing them all (call me anal).
  212.  
  213.   After you have located all the SUID file, now you have to go though 
  214. all these files and decide which files you need, and which you want your 
  215. users to have access to. On my systems, I leave the following files 
  216. SUID, and `chmod 000' the rest of them.
  217.  
  218. passwd
  219. ping
  220. traceroute
  221. screen
  222. su
  223.  
  224.   All other files that may be SUID, users have no business using, unless 
  225. you are going to run some sort of NFS or an X Server. Keep the list of 
  226. SUID files in your home directory so you can remember later where they 
  227. are if you need to use one. The rest of these SUID files, I move and put 
  228. them in the same directory, so I can keep track of them. Mine are in 
  229. `/usr/local/bin' or in `/bin' so that they stay in the users $PATH. 
  230. Later on I'll go into replacement programs for some of these that are 
  231. even more secure. Remember again, it is up to you, the admin, to decide 
  232. what programs you want users to have access to!
  233.  
  234.  
  235. ------------------------------------------------------------------------
  236. 4. Quotas
  237.  
  238.   I always use quotas! Unless your are a normal ISP, or have some reason 
  239. to limit the amount of space each user is allowed to use, most people 
  240. don't bother with quotas. Well that's the wrong attitude and the wrong 
  241. answer. Quotas can totally save your system from getting trashed and 
  242. hosed from an ignorant or destructive user. Quotas not only control how 
  243. much space a user is allowed to use on your system, but it also controls 
  244. the total number of files (inodes) they are allowed to have as well. 
  245. Think about a user who makes a loop that makes directory after directory 
  246. or 1-byte file after 1-byte file? They could not only eat up all the CPU 
  247. and memory, but fill up your drive. A smart set quota can not only stop 
  248. this before it happens, but stop someone who might not have any quota 
  249. from also filling up your hard drive with garbage files. I've tested a 
  250. Linux 3.0 system (Slack), 2.0.20 kernel, filling its hard drive as full 
  251. as it could go, and upon crashing when any command is input, it would 
  252. not boot upon shutting it down and turning it back on. 
  253.  
  254.   To set up quotas on your system, simply select it when you are 
  255. installing your system. It will install the quota set, which includes 
  256. all the programs needed to get them working. Later on you MUST recompile 
  257. your kernel to support quotas, otherwise they won't work. No, I'm not 
  258. going to go into how to compile you kernel. They have very long HOW-TO's 
  259. on how to do it (do a `find' for Kernel-HOWTO.tar.gz). 
  260.  
  261.   Once quota support is added to your kernel, add these lines to your 
  262. `/etc/rc.local' file at the end:
  263.  
  264. # Quota support and file checks
  265. if [ -x /usr/sbin/quotacheck ]
  266.    then
  267.       echo "Checking quotas. This may take some time."
  268.       /usr/sbin/quotacheck -avug
  269.       echo " Done."
  270. fi
  271.  
  272. # Turning ON quotas
  273. if [ -x /usr/sbin/quotaon ]
  274.    then
  275.       echo "Turning on quota."
  276.       /usr/sbin/quotaon -avug
  277. fi
  278.  
  279. # Done
  280.  
  281.  
  282.   Once you reboot, `quotacheck' will first check your file system and 
  283. make sure no one is over quota, along with other house keeps operations, 
  284. then `quotaon' will turn on quota support for your system. A simple 
  285. command of `quota user' will give you the quotas for a user, or `quota 
  286. group' will give you a set quota for a group. To change a quota, issue 
  287. the command `edquota [user] or [group]'. This will open a temp file with 
  288. your editor, as specified in your `.profile', and give you power to 
  289. change a user, or groups quota. For example:
  290.  
  291.  
  292. showdown:/admin/bronc# edquota tidepool
  293.  
  294. Quotas for user tidepool:
  295. /dev/hda1: blocks in use: 279, limits (soft = 10000, hard = 15000)
  296.         inodes in use: 35, limits (soft = 1300, hard = 1500)
  297.  
  298.  
  299.   From here you can see that this users quota on hda1 is 10megs soft, 
  300. and 15megs hard. Which simple gives the user a grace period to go over 
  301. their quota. If they stay over their quota over the grace period (I use 
  302. 10 days), when they login they can't do anything, except delete files. 
  303. The same goes for their files, or inodes. You can set a soft and hard 
  304. limit on these as well. If these are set to `0' then they have no limit 
  305. (bad idea). 
  306.  
  307.   You can use quotas in various ways to secure against on system 
  308. attacks, and your hard drive getting filled up. If you want to get more 
  309. in depth, try `man quota'. It can tell you it's other functions, how to 
  310. manually start and stop this service and where the quota information is 
  311. stored on your system.
  312.  
  313.  
  314. ------------------------------------------------------------------------
  315. 5. Logs
  316.  
  317.   One of the most important parts of being a good system admin is 
  318. regularly reviewing the systems logs, but if you don't know where they 
  319. are, or what you are logging what use are they? This is a very important 
  320. section and I urge you to read it thoroughly! The only way you are going 
  321. to see if you are being probed for an attack, or if someone has been 
  322. attacking you is by checking the logs.
  323.  
  324.   So where are the logs and how is information sent to them? Well on a 
  325. Linux system, they are located in a directory called `/var/adm/' or in a 
  326. directory called `/var/logs' but usually they are linked together. By 
  327. default, there are only two logs, `syslog' and `messages' but we need to 
  328. make more. Logs are made from two daemons, `klogd' and `syslogd'. 
  329. `klogd' intercepts and logs Linux kernel messages, while `syslogd' logs 
  330. all system messages. These are system daemons which are automatically 
  331. started by your `rc.*' files upon boot. To configure what you log, you 
  332. must edit a file called `/etc/syslog.conf', this file tells what 
  333. `syslogd' is to log, and where it is to put it. Here is how I have mine 
  334. set up:
  335.  
  336.  
  337. # /etc/syslog.conf file
  338. # for more information about this file, man `syslog.conf' or `sysklogd'
  339. #
  340. # Modified by Bronc Buster
  341. mail.none;*.=info;*.=notice                     /usr/adm/messages
  342. *.=debug                                        /usr/adm/debug
  343. *.err                                           /usr/adm/syslog
  344. *.=alert                                        root,bronc
  345. *.=emerg                                        root,bronc
  346. authpriv.*;auth.*                               /admin/bronc/auth.log
  347. authpriv.*;auth.*                               /var/log/secure
  348. mail.info;mail.notice                           /var/log/maillog
  349. daemon.info;daemon.notice                       /var/log/daemon.log
  350. *.*                                             /dev/tty12
  351.  
  352. # EOF
  353.  
  354.   Ok, if you don't know how this file is formatted and what phrases to 
  355. use here, read up on the man page, `man syslog.conf'. I don't want to go 
  356. through and waste two or three pages on explaining it. Lets go through 
  357. my file line by line and see how it works. I wanted to make my logs 
  358. simple, easy to understand and be specific as to what they have in them. 
  359. First, my `messages' file was getting full of junk errors from my mail 
  360. program, so I went and took out all messages associated with mail; i.e. 
  361. `mail.none'. Then I wanted all messages at the `info' or `notice' level 
  362. to be placed into it, so I added that into the same line as well. Next, 
  363. I wanted all `debug' messages, sent to their own file, as well as all 
  364. `err' (error) messages. Any `alert' or `emerg' (emergency) messages I 
  365. wanted sent to the console or the terminal I was logged on, so I would 
  366. know about them as soon as possible. The nest two lines have to do with 
  367. connections and possible logins. I wanted to have a file that had 
  368. nothing but who and when, so I could easily check out who logged in and 
  369. when, and I also wanted an extra copy put in my own home directory so 
  370. incase someone somehow edited it and took themselves out, I'd still have 
  371. my own copy plus when I wanted to take a look at it, it was easily 
  372. viewable. That's what the lines with the `authpriv' and `auth' are 
  373. doing. The first one puts the log in my directory, the second in the 
  374. normal logging directory. The next line deals with all the mail messages 
  375. that I took out of the first `messages' file and puts them in their own 
  376. log file. Nothing but mail here, so there is nothing else in there to 
  377. confuse you. The `daemon' line logs all messages regarding the system 
  378. daemons, and, like the mail line above, nothing else so there is nothing 
  379. to get confused over. The last line is also a very important one. It 
  380. sends all logs to /dev/tty12, so even if your logs were to get deleted, 
  381. from the console you can hit Ctrl-F12 and see the last page of messages 
  382. so you can get an idea of what happened. These different logs each cover 
  383. a different aspect of your system, and keep them unscrambled and easy to 
  384. read through. Remember, the easier the better.
  385.  
  386.   If I had another box I could use, I would also pipe all the logs off 
  387. my box to the other box. With syslog, you have the option of sending all 
  388. the logs off your box for remote logging. You could put a poor old 386, 
  389. with Linux, on your network with nothing running but `inetd' and 
  390. `syslogd' and send all your systems logs over to it with this simple 
  391. line in your `syslog.conf':
  392.  
  393.  
  394. # log ALL                       other boxes IP number
  395. #
  396. *.*                             @<boxes IP here>
  397.  
  398.  
  399.   Now that your main system logs are secure, what about other log files? 
  400. You still have `/var/log/wtmp' and `/var/log/utmp', plus each users 
  401. shell histories. Because on some systems, `cron' archives your system 
  402. logs, you normally can't `chattr' them, or mess with them much, but you 
  403. can on the other logs. `chattr' changes a files attributes on an EXT2 
  404. file system, like you are using on your Linux system. With this command, 
  405. you can make a file so it can't be deleted or edited, except to be 
  406. appended (`man chattr' for more info on this useful command). This magic 
  407. command can make the `wtmp' and `utmp' file so it can only be appended 
  408. to, and so it can't be deleted or changed so as to show a user never 
  409. logged on, or where they logged on from. With this same command, you can 
  410. also fix all the users shell histories. Normally, any shell histories 
  411. made by each user, are owned by each user, making them totally useless 
  412. as a skilled user will first thing, link it to `/dev/null'. By using the 
  413. `chattr +a' option of the `chattr' command on `wtmp', `utmp' and each 
  414. users shell histories, you can track down problems quickly. I don't know 
  415. how many troublesome users I have tracked down simply going into their 
  416. shell histories and looking for problems they have caused. Like here is 
  417. an example:
  418.  
  419. --- snip ---
  420. gcc smurf.c -o smurf
  421. smurf <IP edited out>
  422. smurf <IP edited out>
  423. gcc octpuss.c -o octop
  424. octop <IP edited out>
  425. ping <IP edited out>
  426. ping -s 2000 <IP edited out>
  427. rm smurf* 
  428. rm otc*
  429. rm .bash_history
  430. rm .bash_hirtory
  431. vi .bash_history
  432. exit
  433. logout
  434.  
  435.   This, soon removed user, was using denial of service attacks to attack 
  436. another system, and in return they were attacking us. Users like this 
  437. can get you, the admin, in hot water and need to be removed as soon as 
  438. possible. If it wasn't for the fact I `chattr +a' all the users shell 
  439. histories, I never would have tracked it down to a specific user. When I 
  440. add a user, I use a modified the `adduser' script so it automatically 
  441. `chattr +a' their shell histories. To do the same, simply open the 
  442. `adduser' script with an editor and add these lines at the end:
  443.  
  444. # chattr +a users shell histories
  445. if [ -d $HME ]; then
  446.   chmod 711 $HME
  447.   cd $HME
  448.   /bin/touch .bash_history
  449.   /bin/chown $LOGIN:users .bash_history
  450.   /usr/bin/chattr +a .bash_history
  451.   /bin/touch .ksh_history
  452.   /bin/chown $LOGIN:users .ksh_history
  453.   /usr/bin/chattr +a .ksh_history
  454.   /bin/touch .sh_history
  455.   /bin/chown $LOGIN:users .sh_history
  456.   /usr/bin/chattr +a .sh_history
  457. fi
  458.  
  459.  
  460.   You need to keep close tabs on your log files, they are your eyes and 
  461. ears of your system. You need to make them secured, easy to read and 
  462. make sure they cover all aspects of what the system logging daemons can, 
  463. and are logging.
  464.  
  465.  
  466. ------------------------------------------------------------------------
  467. 6. Access Security (remote and physical)
  468.  
  469.   Access is an often-overlooked part of the total security picture. Both 
  470. remote and physical access must be dealt with. It takes more than a 
  471. strong password to keep people off your system, you have to know what 
  472. files to use to control access even if someone were to get a valid login 
  473. and password. There are files in your system that can gratefully help 
  474. and give you stronger control over who connects, as there are also files 
  475. that don't exist and that you need to make that can also help with local 
  476. controls as well. Here are the files we are going to cover then we will 
  477. go onto physical access controls:
  478.  
  479. /etc/suauth
  480. /etc/ftpaccess
  481. /etc/hosts.deny
  482. /etc/hosts.allow
  483. /etc/securetty
  484.  
  485.  
  486.   First, `suauth', it is the file that controls who is allowed to use 
  487. the `su' (Switch User) command. This command, as you know, lets you 
  488. become a root user, or lets you become any other user for that matter 
  489. and is SUID, so you want to keep a tight grip on who is allowed to use 
  490. it. The `suauth' file has a certin format, being:
  491.  
  492. TO:FROM:ACTION
  493.  
  494.   Simple looking enough. The `TO' field tells what user you are going 
  495. to, in this case, say `root'. The `FROM' field controls which user or 
  496. group is being applied to go `TO' root. The `ACTION' tells what to do in 
  497. each case. `ACTION's that can be used are, `OWNPASS', `DENY' and 
  498. `NOPASS'. Here is a clipping out of the `suauth' man page so you can get 
  499. a better feeling of how these all tie together.
  500.  
  501.        
  502.        # A couple of privileged usernames may
  503.        # su to root with their own password.
  504.        #
  505.        root:chris,birddog:OWNPASS
  506.        #
  507.        # Anyone else may not su to root unless in
  508.        # group wheel. This is how BSD does things.
  509.        #
  510.        root:ALL EXCEPT GROUP wheel:DENY
  511.        #
  512.        # Perhaps terry and birddog are accounts
  513.        # owned by the same person.
  514.        # Access can be arranged between them
  515.        # with no password.
  516.        #
  517.        terry:birddog:NOPASS
  518.        birddog:terry:NOPASS
  519.        #
  520.  
  521.   On my system, I have done what is in the second example. I edited the 
  522. `/etc/group' file and added another group called `wheel'. This group is 
  523. somewhere between the group `users' and `root', and I then added the 
  524. users to this group that I wanted to be allowed to `su'. In the `suauth' 
  525. file, I simply told it not to allow anyone to `su' unless they are in 
  526. the group `wheel'. One down. Need any more help, try `man suauth'.
  527.  
  528.   Next is the `ftpaccess' file. This file controls a lot of stuff 
  529. regarding your ftp services, like who can upload and download, if 
  530. anonymous connections are allowed and if there are any hosts you don't 
  531. want connecting at all. Because this file controls so much, I'm only 
  532. going to get into how to block hosts from connecting, as I am dealing 
  533. with access control, so for more information on how to set up other 
  534. features in this file, as always `man ftpaccess'. Now this file has a 
  535. simple rule set, and is not very picky in where you place things in it. 
  536. For example, if we were going to add someone to our deny list, we could 
  537. add it at the very top, the middle or the end and it won't care. I 
  538. usually add them to the bottom as you want room to keep adding. The 
  539. format is a very simple one, `deny <ip or domain> <message file>'. Here 
  540. is how mine looks:
  541.  
  542. # deny these domains from getting on my FTP site
  543. #
  544. #deny      host                    path to nasty message
  545. #
  546. deny    *.sekurity.org                /etc/msgs/msg.dead
  547. deny    *.303.org                     /etc/msgs/msg.dead
  548. dent    *.tacd.org                    /etc/msgs/msg.dead
  549. deny    *.dim.com                     /etc/msgs/msg.dead
  550. deny    *.comsite.net                 /etc/msgs/msg.dead
  551. deny    su1d.technotronic.com         /etc/msgs/msg.dead
  552.  
  553.  
  554.   I think it's very easy to understand the format of this file, except 
  555. maybe the last part, `/etc/msgs/msg.dead'. This is simply a path to a 
  556. text file you want to be shown the person who is denied. Anyone 
  557. connecting and getting access into the system, or getting denied, will 
  558. show up in your log files (/var/logs/secure) so remember to check them 
  559. from time to time if you notice any funny activity.
  560.  
  561.   The `hosts.deny' and `hosts.allow' files work hand in hand with each 
  562. other and are, by default, used on almost all-modern versions of Unix. 
  563. These files work in conjunction with TCP Wrappers, which you are most 
  564. likely using now if you know it or not. TCP Wrappers, in brief, is a 
  565. program called `tcpd'. From the man page, it monitors incoming requests 
  566. for telnet, finger, ftp, exec, rsh, rlogin, tftp, talk, comsat and other 
  567. services that have a one-to-one mapping onto executable files. What does 
  568. that mean? Well in short, it watches programs that are in your 
  569. `/etc/inetd.conf' file which are the programs that are started by 
  570. `inetd' when in incoming request asks for an assigned program it watches 
  571. for. The `tcpd' program is put into the `inetd.conf' file in place of 
  572. the normal programs and whenever a request for service arrives, the 
  573. inetd daemon is tricked into running the `tcpd' program instead of the  
  574. desired server. `tcpd' logs the request and does some additional checks. 
  575. When all is well, `tcpd' runs the appropriate server program and goes 
  576. away. If you look at your `/etc/inetd.conf' file a line should like 
  577. similar to this:
  578.  
  579.  
  580. smtp  stream  tcp     nowait  root    /usr/sbin/tcpd  sendmail -bs
  581.  
  582.  
  583.   Here you can see that my `tcpd' is started, instead of sendmail, when 
  584. an incoming request it sent to my smtp port. `tcpd' then logs the 
  585. request and checks your `hosts.deny' and `host.allow' files. The 
  586. `hosts.*' files do what their names suggest. They allow, or deny 
  587. connections. Their formats are very easy to use; Connection:IP address.
  588.  
  589.  
  590. showdown:~$ cat /etc/hosts.deny
  591. ALL:  130.85.3.8
  592. ALL:  207.172.56.57
  593.  
  594.  
  595.   Here I am blocking ALL connections from these two IP numbers. If I 
  596. wanted I could block the entire class C, or change it to a domain and 
  597. block that. You can put as many IP in here as you want, or if you are 
  598. super paranoid, you can even put `ALL:ALL' and deny all connections.
  599.  
  600.   If you deny everyone, you can then select hosts to allow connections 
  601. from. This is when you would use your `hosts.allow' file. It has the 
  602. same format as the deny file, but unless you deny `ALL:ALL' I've never 
  603. had to use it. But whose to say what your security needs are. Maybe you 
  604. only want a select few people to be allowed to connect to your box. If 
  605. so this is how you would do it. As most of the other files, they can 
  606. also be tweaked a bit more and have other options. To get more 
  607. information on them, `man tcpd'.
  608.  
  609.   Lastly, we will go over another simple, but surpassingly often 
  610. overlooked file. The `/etc/securetty' file simply controls where `root' 
  611. can log in from. As it comes default, it allows root to log in from any 
  612. tty, local or remote. Here is the default:
  613.  
  614.  
  615. console
  616. tty1
  617. tty2
  618. tty3
  619. tty4
  620. tty5
  621. tty6
  622. ttyS0
  623. ttyS1
  624. ttyS2
  625. ttyS3
  626. ttyp0
  627. ttyp1
  628. ttyp2
  629. ttyp3
  630.  
  631.  
  632.   That's all it is. If you had no idea what this file did how would you 
  633. know (`man securetty' maybe)? These are the `/dev/tty's that are on your 
  634. system, remote and local. The `ttyp*' and the `ttyS*' are remote, and 
  635. the rest, as you can guess are local at the console. You, I hope, want 
  636. to keep anyone from logging on as `root' anywhere, except from the local 
  637. tty's. To do this, simply edit this file and comment out all the remote 
  638. tty's with the `#' like so:
  639.  
  640. #Keep root from logging on with a remote /dev/tty
  641. console
  642. tty1
  643. tty2
  644. tty3
  645. tty4
  646. tty5
  647. tty6
  648. #ttyS0
  649. #ttyS1
  650. #ttyS2
  651. #ttyS3
  652. #ttyp0
  653. #ttyp1
  654. #ttyp2
  655. #ttyp3
  656.  
  657.  
  658.   That's that for remote access security. Now I'll move onto physical 
  659. access. Now most places your box is going to be will be secure by the 
  660. nature of place it is. If it is at your ISP, then most likely it is 
  661. secure. If it's co-located, the people at your ISP most likely know you 
  662. and know you box, plus if your box is with theirs, I'm sure they don't 
  663. want anyone back with their machines as much as you don't. If It's on a 
  664. LAN, keep it locked in your office, or if that's not possible, try and 
  665. keep it under a desk or on the floor out of the way where no one will 
  666. notice it. While you can't count on `security through obscurity' online, 
  667. in physical access you want to use it. My box at my ISP is on the bottom 
  668. rack next to 4 other machines that look similar to mine, all with no 
  669. monitors and only keyboards attached (for remote reboots). There are no 
  670. labels or any identifying marks at all. It is out of the way and very 
  671. inconspicuous. If someone is going to go into the place your box is 
  672. stored, you don't want to make it easy to identify, or find for that 
  673. matter. Make them have to hook up a monitor and check each box until 
  674. they find yours. Hopefully they will get discouraged or get cough by 
  675. then. 
  676.  
  677.   A very important note and common sense: NEVER walk away from the 
  678. console and leave root logged in, or any user for that matter. Log out, 
  679. or lock the terminal!
  680.  
  681.   As far as other physical security measures, well if it's sitting in 
  682. your house, what can you do besides lock your doors. If it's at your 
  683. ISP, you have to rely on them. If it's at work, keep it out of sight or 
  684. locked up. Just be smart. Keep the console locked. Don't leave a monitor 
  685. hooked up to it if it's not at your house. If someone wants to get to 
  686. it, it's not like it's going to be kept in some top-secret lab 
  687. somewhere, they are going to get to it. If they do, try and make it so 
  688. the most damage they can do is to simply turn it off.
  689.  
  690.  
  691. ------------------------------------------------------------------------
  692. 7. Misc. Files
  693.  
  694.   Now I am going to cover the other files around the system that don't 
  695. fall under the other categories I've went through so far. There are only 
  696. a few, but they are an important few. These files are:
  697.  
  698. /etc/inetd.conf
  699. /etc/services
  700. /etc/nologin
  701. /etc/issue.net and /etc/issue
  702. /etc/passwd
  703. /etc/shadow
  704. /etc/group
  705.  
  706.   First, the `inetd.conf' file. This file is the configuration file for 
  707. your `inetd' daemon. This daemon listens for connections on certain 
  708. ports for and then decides what service to invoke, if any as told to it 
  709. by the `inetd.conf' file. As you can imagine, this is an important file 
  710. as whatever services are in it can be invoked by it. As default, all the 
  711. services in it are open. I guess the writers of it though we were living 
  712. in lollypop land and everyone was friendly, but unfortunately it's not. 
  713.  
  714.   To edit this file, as with the ones before, you use `#'. You're 
  715. `inetd.conf' file should look similar to this one before being edited:
  716.  
  717.  
  718. -------- snip ---------
  719.  
  720. # The first 4 services are really only used for debugging purposes, so
  721. # we comment them out since they can otherwise be used for some nasty
  722. # denial-of-service attacks.  If you need them, uncomment them.
  723.  echo          stream  tcp     nowait  root    internal
  724.  echo          dgram   udp     wait    root    internal
  725.  discard       stream  tcp     nowait  root    internal
  726.  discard       dgram   udp     wait    root    internal
  727.  daytime       stream  tcp     nowait  root    internal
  728.  daytime       dgram   udp     wait    root    internal
  729.  chargen       stream  tcp     nowait  root    internal
  730.  chargen       dgram   udp     wait    root    internal
  731. time    stream  tcp     nowait  root    internal
  732. time    dgram   udp     wait    root    internal
  733. #
  734. # These are standard services.
  735. #
  736. ftp     stream  tcp     nowait  root    /usr/sbin/tcpd  wu.ftpd -l -i -a
  737. telnet  stream  tcp     nowait  root    /usr/sbin/tcpd  in.telnetd
  738. #
  739. #
  740. # Use this one instead if you want to snoop on telnet users (try to use 
  741. this
  742. # for ethical purposes, ok folks?) :
  743. # telnet stream  tcp     nowait  root    /usr/sbin/tcpd 
  744. /usr/sbin/in.telnetsnoopd
  745. #
  746. # This is generally unnecessary.  The daemon provided by INN will handle 
  747. the
  748. # incoming NNTP connections.
  749.  nntp  stream  tcp     nowait  root    /usr/sbin/tcpd  in.nntpd
  750. #
  751.  
  752. ----- snip -----
  753.  
  754. smtp  stream  tcp     nowait  root    /usr/sbin/tcpd  sendmail -bs
  755. #
  756. # The comsat daemon notifies the user of new mail when biff is set to y:
  757. comsat        dgram   udp     wait    root    /usr/sbin/tcpd  in.comsat
  758. #
  759. # Shell, login, exec and talk are BSD protocols.
  760. #
  761. shell  stream  tcp     nowait  root    /usr/sbin/tcpd  in.rshd -L
  762. login  stream  tcp     nowait  root    /usr/sbin/tcpd  in.rlogind
  763. exec  stream  tcp     nowait  root    /usr/sbin/tcpd  in.rexecd
  764. talk    dgram   udp     wait    root    /usr/sbin/tcpd  in.talkd
  765. ntalk   dgram   udp     wait    root    /usr/sbin/tcpd  in.talkd
  766. # Kerberos authenticated services
  767. #
  768. # klogin    stream  tcp     nowait  root    /usr/sbin/tcpd  rlogind -k
  769. # eklogin   stream  tcp     nowait  root    /usr/sbin/tcpd  rlogind-k -x
  770. # kshell        stream  tcp     nowait  root    /usr/sbin/tcpd  rshd -k
  771. #
  772. # Services run ONLY on the Kerberos server
  773. #
  774. # krbupdate stream  tcp     nowait  root    /usr/sbin/tcpd   registerd
  775. # kpasswd   stream  tcp     nowait  root    /usr/sbin/tcpd  kpasswdd
  776. #
  777. # Pop et al
  778. #
  779.  pop2  stream  tcp     nowait  root    /usr/sbin/tcpd  in.pop2d
  780.  pop3  stream  tcp     nowait  root    /usr/sbin/tcpd  in.pop3d
  781. # The ipop3d POP3 server is part of the Pine distribution.  If you've
  782. # installed the Pine package, you may wish to switch to ipop3d by 
  783. # commenting out the pop3 line above, and uncommenting the pop3 line 
  784. below.
  785. pop3    stream  tcp     nowait  root    /usr/sbin/tcpd  ipop3d
  786. imap2   stream  tcp     nowait  root    /usr/sbin/tcpd  imapd
  787. #
  788. # The Internet UUCP service.
  789. #
  790.  uucp  stream  tcp  nowait  uucp /usr/sbin/tcpd /usr/lib/uucp/uucico-l
  791. #
  792. # Tftp service is provided primarily for booting.  Most sites
  793. # run this only on machines acting as "boot servers." 
  794. #
  795.  tftp  dgram   udp     wait    nobody  /usr/sbin/tcpd  in.tftpd
  796. # bootps dgram   udp  wait root /usr/sbin/in.bootpd     in.bootpd
  797. #
  798. # Finger, systat and netstat give out user information which may be
  799. # valuable to potential "system crackers."  Many sites choose to disable 
  800. # some or all of these services to improve security.
  801. # Try "telnet localhost systat" and "telnet localhost netstat" to see 
  802. # that
  803. # information yourself!
  804. #
  805. finger  stream  tcp     nowait  nobody  /bin/sbin/tcpd  in.fingerd
  806. systat  stream  tcp     nowait  nobody  /usr/sbin/tcpd  /bin/ps -auwwx
  807. netstat stream  tcp     nowait  root    /usr/sbin/tcpd  /bin/netstat-a
  808. #
  809. # Ident service is used for net authentication
  810. auth stream  tcp  wait root /usr/sbin/in.identd in.identd -w-t1 20 -l
  811. #
  812. #
  813. # These are to start Samba, an smb server that can export filesystems to
  814. # Pathworks, Lanmanager for DOS, Windows for Workgroups, Windows95, 
  815. #Lanmanager
  816. # for Windows, Lanmanager for OS/2, Windows NT, etc.  
  817. # If you're running smbd and nmbd from daemons in /etc/rc.d/rc.samba, 
  818. #then you
  819. # shouldn't uncomment these lines.
  820.  netbios-ssn     stream  tcp     nowait  root    /usr/sbin/smbd  smbd
  821.  netbios-ns      dgram   udp     wait    root    /usr/sbin/nmbd  nmbd
  822. #
  823. # Sun-RPC based services.
  824. # <service name/version><sock_type><rpc/prot><flags><user><server><args>
  825. # rstatd/1-3 dgram rpc/udp wait root    /usr/sbin/tcpd  rpc.rstatd
  826. # rusersd/2-3 dgram rpc/udp wait root    /usr/sbin/tcpd  rpc.rusersd
  827. # walld/1   dgram   rpc/udp wait    root    /usr/sbin/tcpd  rpc.rwalld
  828. #
  829. # End of inetd.conf.
  830.  
  831.  
  832.   This is a cut down version, but should look very similar to yours. You 
  833. need to take some of these services out; the ones you don't use and the 
  834. ones you don't need. Some of them tell you what they are used for, 
  835. others don't. You need to go through and see what services you need, and 
  836. what you don't.
  837.  
  838.   For a normal server, I have almost all these services edited out, as 
  839. they are not used or pose security risks. Here are the services I left 
  840. open in mine:
  841.  
  842. time    stream  tcp     nowait  root    internal
  843. time    dgram   udp     wait    root    internal
  844. ftp     stream  tcp     nowait  root    /usr/sbin/tcpd  wu.ftpd -l -i -a
  845. telnet  stream  tcp     nowait  root    /usr/sbin/tcpd  in.telnetd
  846. smtp    stream  tcp     nowait  root    /usr/sbin/tcpd  sendmail -bs
  847. talk    dgram   udp     wait    root    /usr/sbin/tcpd  in.talkd
  848. ntalk   dgram   udp     wait    root    /usr/sbin/tcpd  in.talkd
  849. auth  stream  tcp wait root  /usr/sbin/in.identd  in.identd -w -t1 20 -l
  850.  
  851.   All the other services I don't use, or can do without. These are 
  852. essential services that are needed for a server that has users on it. 
  853. These are services they need so they may connect, send mail, and other 
  854. basic user activities (ftp, telnet, smtp, talk, ntalk), plus a few other 
  855. to help me verify connections (auth). All the others you can edit out 
  856. without fear of cutting off users or hurting the system.
  857.  
  858.   I also modified my finger service a bit. I usually have it turned off, 
  859. but for fun I did this:
  860.  
  861.  
  862. finger  stream  tcp     nowait  nobody  /bin/cat cat /etc/finger.txt
  863.  
  864.  
  865.   All this does is, instead of returning the normal `finger' 
  866. information, is echo a file, the file `/etc/finger.txt', back to the 
  867. person who has fingered your system. You can put whatever you want to be 
  868. in the `finger.txt' file, so have a bit of fun with it :).
  869.  
  870.   The `/etc/services' file lists the ports on your system that have 
  871. services connected to them. Think of them like a bunch of open windows 
  872. that you can go through. You want to close all the windows you're not 
  873. using or watching because most remote exploits are run on ports that are 
  874. running some obscure service that no one thinks about or uses. If you 
  875. take a look at this file, you'll see it's quite large. It lists port 
  876. numbers with the protocol and the service on each port. You can also 
  877. edit out ports with the `#' in this file. Here is the man pages 
  878. definition: `services' is a plain ASCII file providing a mapping between 
  879. friendly textual names for internet  services,  and  their underlying 
  880. assigned port numbers and protocol types. Every networking program 
  881. should look into this file to get the port number (and protocol) for its 
  882. service. 
  883.  
  884.   Instead of showing you all the ports, I'll show you what ports I have 
  885. open, and you can see how they correspond to my `inetd.conf'.
  886.  
  887.  
  888. netstat         15/tcp
  889. ftp             21/tcp
  890. ssh             22/tcp          #Secure SHell
  891. telnet          23/tcp
  892. smtp            25/tcp          mail
  893. time            37/tcp          timserver
  894. time            37/udp          timserver
  895. whois           43/tcp          nicname
  896. finger          79/tcp
  897. www             80/tcp          http    # WorldWideWeb HTTP
  898. www             80/udp                  # HyperText Transfer Protocol
  899. auth            113/tcp         tap ident authentication
  900. talk            517/udp
  901. ntalk           518/udp
  902.  
  903.  
  904.   As you can see, the majority of the ports do not need to be open. You 
  905. need to run the minimum number of ports to get the job done. If you're 
  906. not sure if what a port does, try using `man' and checking what the 
  907. service is. You can even block a port and see how it goes, then, if 
  908. needed, come back and unblock it later. One note you want to remember. 
  909. If the service is open in the `inetd.conf' file, then you also want it 
  910. to be open in this file as well.
  911.  
  912.   The next file is `/etc/nologin'. This file may be useful when you need 
  913. to lockdown the system to find a problem where you need all the users 
  914. off the system, track down a problem user or stop a hacker in progress. 
  915. By simply making a file called `nologin', or what is commonly done is 
  916. `mv'ing the `motd' file, no non-root users will be allowed to log on to 
  917. the system. The system will let them log on, it will then echo to them 
  918. whatever is in the `nologin' file, then terminate their connection. 
  919.  
  920.  
  921.   The `/etc/issue.net' and the `/etc/issue' files can be important in 
  922. taking away a good way of getting information on your system. A lot of 
  923. people will simply telnet to a system and look at the login prompt to 
  924. see what type of operating system is running. By changing the `issue' 
  925. file instead of telnet showing this:
  926.  
  927.  
  928. Welcome to Linux 2.0.35.
  929. Showdown login:_
  930.  
  931.  
  932.   You can make it show whatever you want. Both of these files are plain 
  933. ASCII files. Simply edit it and put in whatever you want:
  934.  
  935.  
  936. \__ ^^ __/     
  937.    X  X 
  938.    \  /                     
  939.     \/
  940.  
  941. Welcome to eLe3t mIcRoSoFt uNiX v6.66
  942. Showdown login:_
  943.  
  944.  
  945.   The `/etc/passwd', `/etc/shadow' and the `/etc/group' files I hope you 
  946. already know are very important files. They hold the power is the system 
  947. and tells the system, who is who and who has the power to do what. I 
  948. hope, as you are the admin of a box, you know how important these files 
  949. are. You need to insure the passwords are strong, that there are no 
  950. users with no passwords, there are no other users except root with the 
  951. UID of 0 and that the permission on the files are set correctly. By 
  952. default the permissions are correct, so don't change them. The Shadow 
  953. Suite takes good care of things though security wise, so besides these 
  954. simple things, you don't have to worry much about them. Take a chance to 
  955. look through all three of these files and familiarize yourself with them 
  956. so you can spot a problem if one were to appear.
  957.  
  958.  
  959. ------------------------------------------------------------------------
  960. 8. Third Party Tools
  961.  
  962.   Well this part I threw in because I have found some free tools 
  963. floating around the net that are extremely useful. Some of these tools 
  964. are `must gets'.
  965.  
  966.  
  967. SSH 
  968.  
  969.   If you are not running SSH, you need to be. SSH uses keys, similar to 
  970. PGP, to authenticate logins and then encrypts the session both to and 
  971. from the server. Someone running a network packet sniffer can very 
  972. easily capture logins and passwords from another unsecured machine on 
  973. your LAN, but not if you use SSH. Most newer SSH clients support vt100 
  974. and all the cool ASCII colors, and such so by getting it, you're not 
  975. losing anything, but your gaining a piece of mind and some real 
  976. security. 
  977.  
  978.   You can get SSH and read more about it at:
  979.  
  980. SSH FAQ's - http://www.uni-karlsruhe.de/~ig25/ssh-faq/
  981. FiSSH, Free SSH Win95/NT client - http://www.massconfusion.com/ssh/
  982. SSH Club FI - http://www.cs.hut.fi/ssh/
  983.  
  984.  
  985. Sentry
  986.  
  987.   Although still in Beta form, this is a super useful program I now run 
  988. on all my systems. Here is a clipping from its README file to briefly 
  989. tell what it does:
  990.  
  991. The Sentry is part of the Abacus Project suite of tools. The Abacus 
  992. Project is an initiative to release low-maintenance, generic, and 
  993. reliable host based intrusion detection software to the Internet 
  994. community. 
  995.  
  996.   This program listens to ports, you designate, and takes actions 
  997. depending on different rules you set for it. This is to give you a heads 
  998. up that someone may be probing your system, or launching DoS attacks 
  999. against it. It can log the activity, can add the offending hosts to the 
  1000. `/etc/hosts.deny' file, the local system can be automatically re-
  1001. configured to route all traffic to the target to a dead host to make the 
  1002. target system disappear and it can also be re-configured to drop all 
  1003. packets from the host via a local packet filter.
  1004.  
  1005.   All and all it's a program I think you need to install, understand and 
  1006. use.
  1007.  
  1008.   You can get more information and get Sentry at:
  1009.  
  1010. Sentry Abacus Project - http://www.psionic.com/abacus/abacus_sentry.html
  1011.  
  1012.  
  1013. Logcheck
  1014.  
  1015.   This tool is also part of the Abacus Project and is a must get. When 
  1016. used in conjunction with SSH and Sentry, it can keep you easily informed 
  1017. to the happenings around your system. This program, via cron, checks 
  1018. your logs on a timed basis looking for certain key words that can 
  1019. trigger a level of alert. Like Sentry, you set the rules as to what it 
  1020. looks for and what it does, and it's easily configurable. It can do 
  1021. simple things like e-mail you, or echo to your console or even shut down 
  1022. the system depending on what rules you give it.
  1023.  
  1024.   You can get more information and get Logcheck at:
  1025.  
  1026. Logcheck Abacus Project -
  1027. http://www.psionic.com/abacus/abacus_logcheck.html
  1028.  
  1029.  
  1030. Secure Ping v1.0
  1031.  
  1032.   This is a secure replacement for the normal `ping' program on your 
  1033. system. `ping' is often abused by users trying to icmp other hosts with 
  1034. the feared pings-of-death and the like. This program limits both users 
  1035. and root as to the sizes of packets and the number of packets that can 
  1036. be sent. If someone tried to abuse Secure Ping, it simply tells the user 
  1037. to take a hike and then sends a line to the log files which Logcheck 
  1038. then picks up later and tells you about.
  1039.  
  1040.   You can get more information and get Secure Ping at:
  1041.  
  1042. Secure Ping - http://www.sy.net/security
  1043.  
  1044.  
  1045. Smurf Logger v1.1
  1046.  
  1047.   This program does what its name says. It logs ICMP Smurf attacks. 
  1048. Unlike a normal ICMP Ping logger, this won't fill up your hard drive 
  1049. with meg after meg of logs. It logs repeat attacks with one line. This 
  1050. is also a nice program to have so you can see if your box is getting hit 
  1051. or not, and then take actions to block it at the router level.
  1052.  
  1053. You can get more information and get Smurf Logger v1.1 at:
  1054.  
  1055. Smurf Logger - http://www.sy.net/security
  1056.  
  1057.  
  1058. Tripwire
  1059.  
  1060.   Tripwire is a tool to use just incase your system has been breached. 
  1061. Once installed correctly, with a correct config file, this program will 
  1062. look at all the files on your system, see their sizes and their dates 
  1063. then, whenever you want, will recheck them to see if they match. This is 
  1064. a good way to find out if a file has been tampered with, trojened or 
  1065. backdoored. The only draw back is that you need to keep a read-only 
  1066. floppy in the floppy drive.
  1067.  
  1068.   You can get more information and get Tripwire at:
  1069.  
  1070. COAST Archives - ftp://coast.cs.purdue.edu/pub/COAST/Tripwire
  1071.  
  1072.  
  1073. Lsof
  1074.  
  1075.   This handy file checks for files on the system that are open. They can 
  1076. either be legit files that are opened, like eggdrop files, or they can 
  1077. be files that someone `forgot' to close and is eating up 100% CPU. This 
  1078. is another handy file to have in your arsenal.
  1079.  
  1080. Prudue Unix Tools - ftp://vic.cc.purdue.edu/pub/tools/unix/lsof/
  1081.  
  1082.  
  1083.  
  1084.   Well I know there are a ton of other programs out there floating all 
  1085. over the net that, and maybe there are some that do a better job then 
  1086. these do, but these are the ones that I use and the ones I have found 
  1087. that work and are easy to use. As new program come out everyday, you 
  1088. have to keep on the lookout for what's new, and look for what's best for 
  1089. your needs.
  1090.  
  1091.  
  1092.  
  1093. ------------------------------------------------------------------------
  1094. 9. Conclusions
  1095.  
  1096.  
  1097.   Well, as you can see by the shear length of this paper that security 
  1098. for an operating system like Linux is not as simple as it may look. This 
  1099. paper has only touched on the basics of a lot of things you must know 
  1100. and get familiar with. This paper, if in depth, could of gone on to be a 
  1101. book (and I could of charged $50, hehehe), but as with all good papers, 
  1102. it's a work in progress. 
  1103.  
  1104.   The bottom line is you have to plan what your needs are going to be. 
  1105. You must implement you system to meet your needs, and then you have to 
  1106. be alert. The admin of a system is the bottom line when it comes to 
  1107. security. The admin must stay alert and watch his system, he must watch 
  1108. the security posts and mailing lists and must keep informed when new 
  1109. patches, kernels and programs come out. An admin must also keep their 
  1110. up-streams informed as well, and stay in good contact with them so they 
  1111. may trade valuable information with you so you both know what is going on. 
  1112. Heck, you can go on forever about what a good sys admin has to do to 
  1113. keep a secure system, but you have to start with knowing your system. I 
  1114. hope this paper has helped.
  1115.  
  1116. ------------------------------------------------------------------------
  1117.  
  1118.  
  1119.  
  1120. [EOF]
  1121.  
  1122. check out the underground -- http://www.legions.org